Event Sourcing архитектура: Дълбоко гмуркане в системите за съхранение на домейнови събития

Event Sourcing е архитектурен модел, при който състоянието на дадено приложение се определя от последователност от събития. Вместо да съхраняваме текущото състояние на дадена същност, ние запазваме серия от непроменими събития, които представляват промени в тази същност. Тази публикация в блога ще разгледа Event Sourcing архитектурата в детайли, като се фокусира конкретно върху системите за съхранение на домейнови събития.

Какво е Event Sourcing?

В традиционните системи текущото състояние на дадена същност се съхранява директно в база данни. Когато възникне актуализация, съществуващият запис се променя или презаписва. Този подход работи добре за много приложения, но има ограничения, когато:

• Одитът и проследяването на историята са от решаващо значение.
• Трябва да се реконструират сложни преходи на състоянието.
• Изискват се разпространение на данни в реално време и архитектури, управлявани от събития.

Event Sourcing адресира тези ограничения, като съхранява всяка промяна на състоянието като непроменимо събитие. Тези събития се запазват в event store, който позволява само добавяне. За да се реконструира текущото състояние на дадена същност, събитията се възпроизвеждат в реда, в който са възникнали. Мислете за това като за счетоводна книга, където всяка транзакция се записва и салдото се изчислява чрез сумиране на всички транзакции.

Ключови концепции

• Домейн събитие: Факт, представляващ нещо, което се е случило в домейна. Това е непроменим запис на промяна на състоянието. Примерите включват OrderCreated, OrderShipped, PaymentReceived.
• Event Store: Хранилище за данни, което позволява само добавяне и е оптимизирано за съхранение и извличане на домейнови събития. То предоставя механизми за запазване, извличане и абонамент за събития.
• Обработчици на събития: Компоненти, които реагират на домейнови събития. Те могат да актуализират модели за четене, да задействат външни интеграции или да извършват други действия.
• Модели за четене: Денормализирани представяния на данни, оптимизирани за конкретни модели на заявки. Те се актуализират от обработчици на събития и предоставят изглед на данните само за четене.
• Snapshotting: Техника, използвана за оптимизиране на реконструкцията на състоянието чрез периодично съхраняване на текущото състояние на дадена същност. При реконструиране на състоянието, системата зарежда най-новата моментна снимка и възпроизвежда само събитията, които са възникнали след направата на моментната снимка.

Предимства на Event Sourcing

Event Sourcing предлага няколко предимства пред традиционните CRUD (Create, Read, Update, Delete) архитектури:

• Пълна одитна следа: Всяка промяна на състоянието се записва като събитие, осигурявайки цялостна история на данните на приложението. Това е безценно за одит, отстраняване на грешки и съответствие.
• Временни заявки: Възможността да се извършва заявка към състоянието на дадена същност във всеки един момент във времето. Това позволява исторически анализ и отчитане. Например, можете да определите броя на поръчките, направени в определен регион на определена дата.
• Опростено отстраняване на грешки: Чрез възпроизвеждане на събития можете да пресъздадете всяко минало състояние на приложението, което улеснява идентифицирането и отстраняването на грешки.
• Подобрена производителност за определени операции: Докато реконструирането на състоянието може да бъде по-бавно, актуализирането на модели за четене може да бъде силно оптимизирано за конкретни модели на заявки.
• Архитектура, управлявана от събития: Event Sourcing естествено се привежда в съответствие с архитектурите, управлявани от събития, позволявайки разпространение на данни в реално време и интеграция с други системи.
• По-лесна еволюция: Добавянето на нови функции или модифицирането на съществуващи често е по-лесно, защото можете просто да добавите нови обработчици на събития, без да засягате съществуващия поток от събития.
• Подобрена мащабируемост: Разпределянето на обработката на събития между няколко възела може да подобри мащабируемостта и устойчивостта.

Предизвикателства на Event Sourcing

Event Sourcing също така представя някои предизвикателства, които трябва да бъдат внимателно обмислени:

• Сложност: Внедряването на Event Sourcing изисква различен начин на мислене и по-задълбочено разбиране на моделирането на домейни и принципите, управлявани от събития.
• Евентуална консистентност: Моделите за четене са евентуално консистентни с event store, което може да доведе до забавяния и несъответствия в потребителския интерфейс. Трябва да се внедрят стратегии за справяне с евентуалната консистентност, като например оптимистично заключване или компенсиращи транзакции.
• Версиониране на събития: Тъй като приложението се развива, структурата на домейновите събития може да се промени. Трябва да се внедрят стратегии за справяне с версионирането на събития, като например миграция на събития или еволюция на схемата, за да се осигури обратна съвместимост.
• Реконструкция на състоянието: Реконструирането на състоянието на дадена същност чрез възпроизвеждане на събития може да отнеме много време, особено за същности с голям брой събития. Snapshotting може да помогне за облекчаване на този проблем.
• Избор на правилния Event Store: Изборът на подходящ event store, който отговаря на изискванията на приложението за производителност, мащабируемост и надеждност, е от решаващо значение.

Системи за съхранение на домейнови събития: Сравнителен преглед

1. Релационни бази данни (SQL)

Релационни бази данни като PostgreSQL, MySQL и SQL Server могат да бъдат използвани като event stores. Въпреки че предлагат ACID (Atomicity, Consistency, Isolation, Durability) свойства и силна консистентност на данните, те може да не са най-ефективният избор за обработка на събития с висока пропускателна способност.

Предимства:

• ACID свойства: Гарантира целостта и консистентността на данните.
• Зряла технология: Добре установена технология с обширни инструменти и поддръжка.
• Познатост: Повечето разработчици са запознати с релационните бази данни.
• Силна консистентност: Предоставя силни гаранции за консистентност.

Недостатъци:

• Пречки пред производителността: Може да се превърне в пречка пред производителността за потоци от събития с голям обем.
• Предизвикателства при еволюцията на схемата: Справянето с промените в схемата може да бъде сложно и да изисква внимателно планиране.
• Ограничения на мащабируемостта: Мащабирането на релационни бази данни може да бъде предизвикателство, особено за работни натоварвания с много операции за запис.
• Не са оптимизирани за операции, които позволяват само добавяне: Релационните бази данни не са специално проектирани за операции, които позволяват само добавяне, което може да повлияе на производителността.

Пример за внедряване (PostgreSQL):

Създайте таблица за съхранение на домейнови събития:

            CREATE TABLE events (
  event_id UUID PRIMARY KEY,
  aggregate_id UUID NOT NULL,
  event_type VARCHAR(255) NOT NULL,
  event_data JSONB NOT NULL,
  created_at TIMESTAMP WITHOUT TIME ZONE NOT NULL DEFAULT (NOW() AT TIME ZONE 'utc')
);

            

              
                Copy
              
            
          

Вмъкнете ново събитие:

            INSERT INTO events (event_id, aggregate_id, event_type, event_data)
VALUES (uuid_generate_v4(), 'a1b2c3d4-e5f6-7890-1234-567890abcdef', 'OrderCreated', '{"orderId": "ORD-123", "customerId": "CUST-456", "amount": 100}');

            

              
                Copy
              
            
          

2. NoSQL бази данни

NoSQL бази данни, като например MongoDB, Cassandra и Couchbase, предлагат повече гъвкавост и мащабируемост в сравнение с релационните бази данни. Те са много подходящи за обработка на потоци от събития с голям обем, но могат да предоставят по-слаби гаранции за консистентност на данните.

Предимства:

• Мащабируемост: Проектирани са за хоризонтална мащабируемост и могат да обработват големи обеми данни.
• Гъвкавост: Безсхемната или гъвкавата схема позволява по-лесно версиониране на събития.
• Производителност: Оптимизирани са за операции за четене и запис с висока пропускателна способност.
• Рентабилни: Може да бъдат по-рентабилни от релационните бази данни за определени работни натоварвания.

Недостатъци:

• Евентуална консистентност: Може да предоставят по-слаби гаранции за консистентност на данните в сравнение с релационните бази данни.
• Сложност: Изисква по-задълбочено разбиране на концепциите за NoSQL бази данни и техниките за моделиране на данни.
• Зрялост: Някои NoSQL бази данни са по-малко зрели от релационните бази данни.
• Ограничения при заявките: Възможностите за извършване на заявки може да бъдат ограничени в сравнение с релационните бази данни.

Пример за внедряване (MongoDB):

Съхранявайте домейнови събития в колекция:

            {
  "event_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "aggregate_id": "f1g2h3i4-j5k6-l7m8-n9o0-p1q2r3s4t5uv",
  "event_type": "OrderCreated",
  "event_data": {
    "orderId": "ORD-123",
    "customerId": "CUST-456",
    "amount": 100
  },
  "created_at": ISODate("2023-10-27T10:00:00.000Z")
}

            

              
                Copy
              
            
          

3. Специализирани Event Stores

Специализирани event stores, като например EventStoreDB и AxonDB, са проектирани специално за Event Sourcing. Те предоставят функции като съхранение, което позволява само добавяне, версиониране на събития и управление на потоци. Тези бази данни обикновено са най-добрият избор, ако сте сериозни за event sourcing.

Предимства:

• Оптимизирани за Event Sourcing: Проектирани са специално за event sourcing с функции като съхранение, което позволява само добавяне, управление на потоци и версиониране на събития.
• Висока производителност: Оптимизирани са за обработка на събития с висока пропускателна способност.
• Обработване на евентуалната консистентност: Вградени механизми за справяне с евентуалната консистентност.
• Управление на потоци: Опростява управлението и извършването на заявки към потоци от събития.

Недостатъци:

• Зависимост от доставчик: Може да въведе зависимост от доставчик.
• Цена: Може да бъде по-скъпо от други опции.
• Крива на обучение: Изисква изучаване на нова технология.
• Ограничено приемане: По-слабо разпространени от релационните и NoSQL бази данни.

Пример за внедряване (EventStoreDB):

EventStoreDB използва потоци за съхранение на събития. Можете да добавяте събития към поток, използвайки клиентската библиотека на EventStoreDB.

4. Опашки за съобщения (Kafka, RabbitMQ)

Опашки за съобщения като Apache Kafka и RabbitMQ могат да бъдат използвани като event stores, особено във връзка с рамки за обработка на потоци. Те осигуряват висока пропускателна способност, мащабируемост и устойчивост на грешки, което ги прави подходящи за мащабни приложения, управлявани от събития. Въпреки това, те обикновено се използват повече като преходен транспортен механизъм, отколкото като постоянно хранилище.

Предимства:

• Висока пропускателна способност: Проектирани са за обработка на съобщения с висока пропускателна способност.
• Мащабируемост: Силно мащабируеми и могат да обработват големи обеми събития.
• Устойчивост на грешки: Вградени механизми за устойчивост на грешки.
• Обработка в реално време: Позволява обработка на събития в реално време.

Недостатъци:

• Сложност: Изисква по-задълбочено разбиране на концепциите за опашки за съобщения и рамките за обработка на потоци.
• Устойчивост на данните: Устойчивостта на данните трябва да бъде внимателно конфигурирана.
• Възпроизвеждане на събития: Възпроизвеждането на събития може да бъде по-сложно, отколкото при специализирани event stores.
• Гаранции за подреждане: Гаранциите за подреждане може да бъдат ограничени в зависимост от конфигурацията.

Пример за внедряване (Apache Kafka):

Публикувайте домейнови събития в тема на Kafka:

            // Producer configuration
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

Producer<String, String> producer = new KafkaProducer<>(props);

// Create a record
ProducerRecord<String, String> record = new ProducerRecord<String, String>("order-events", "ORD-123", "{"event_type": "OrderCreated", "customerId": "CUST-456", "amount": 100}");

// Send the record
producer.send(record);

producer.close();

            

              
                Copy
              
            
          

5. Облачни Event Stores

Облачните доставчици предлагат управлявани услуги за event store, като например Azure Event Hubs, AWS Kinesis и Google Cloud Pub/Sub. Тези услуги осигуряват мащабируемост, надеждност и лекота на използване, което ги прави добър избор за облачни приложения.

Предимства:

• Мащабируемост: Силно мащабируеми и могат да обработват големи обеми събития.
• Надеждност: Вградена надеждност и устойчивост на грешки.
• Лекота на използване: Управляваните услуги опростяват внедряването и поддръжката.
• Интеграция: Безпроблемна интеграция с други облачни услуги.

Недостатъци:

• Зависимост от доставчик: Въвежда зависимост от доставчик.
• Цена: Може да бъде по-скъпо от самостоятелно управлявани решения.
• Латентност: Мрежовата латентност може да повлияе на производителността.
• Контрол: По-малък контрол върху основната инфраструктура.

Съображения за производителността

Производителността е критичен фактор при избора на система за съхранение на домейнови събития. Ето някои съображения за производителността, които трябва да имате предвид:

• Пропускателна способност на запис: Възможността за обработка на голям обем входящи събития.
• Латентност на четене: Времето, необходимо за извличане на събития и реконструиране на състоянието на дадена същност.
• Едновременност: Възможността за обработка на едновременни операции за четене и запис.
• Капацитет за съхранение: Количеството място за съхранение, необходимо за съхранение на събития.
• Мрежова латентност: Латентността между приложението и event store.

За да оптимизирате производителността, обмислете следните техники:

• Групиране: Групирането на събития преди записването им в event store може да подобри пропускателната способност на запис.
• Кеширане: Кеширането на често достъпвани събития може да намали латентността на четене.
• Snapshotting: Snapshotting може да намали броя на събитията, които трябва да бъдат възпроизведени при реконструиране на състоянието на дадена същност.
• Индексиране: Индексирането на събития въз основа на ID на агрегат и други релевантни атрибути може да подобри производителността на заявките.
• Разделяне: Разделянето на event store между множество възли може да подобри мащабируемостта и производителността.

Целост на данните

Целостта на данните е от първостепенно значение в Event Sourcing. От решаващо значение е да се гарантира, че събитията се запазват надеждно и в правилния ред. Ето някои стратегии за поддържане на целостта на данните:

• Транзакции: Използвайте транзакции, за да гарантирате, че събитията се записват атомарно в event store.
• Идемпотентност: Проектирайте обработчиците на събития да бъдат идемпотентни, което означава, че те могат да обработват едно и също събитие многократно, без да причиняват непредвидени странични ефекти.
• Оптимистично заключване: Използвайте оптимистично заключване, за да предотвратите едновременни актуализации на един и същ агрегат.
• Валидиране на събития: Валидирайте събитията преди да ги запазите в event store, за да се уверите, че са валидни и консистентни.
• Контролни суми: Изчислете контролни суми за събития и ги съхранявайте заедно със събитията. Проверете контролните суми при извличане на събития, за да се уверите, че не са били повредени.

Версиониране на събития

Тъй като приложението се развива, структурата на домейновите събития може да се промени. Справянето с версионирането на събития е от решаващо значение за осигуряване на обратна съвместимост и предотвратяване на загуба на данни. Ето някои стратегии за справяне с версионирането на събития:

• Event Upcasting: Трансформирайте по-старите версии на събития към най-новата версия, когато ги четете от event store.
• Еволюция на схемата: Развивайте схемата на събитията с течение на времето, като добавяте нови полета или модифицирате съществуващи. Уверете се, че по-старите версии на събитията все още могат да бъдат обработени правилно.
• Миграция на събития: Мигрирайте по-стари събития към най-новата версия на схемата. Това може да се извърши като фонов процес.

Примери от реалния свят

Event Sourcing се използва в различни индустрии и приложения. Ето няколко примера от реалния свят:

• Електронна търговия: Проследяване на историята на поръчките, промените в инвентара и активността на клиентите. Например, глобална платформа за електронна търговия може да използва Event Sourcing за проследяване на поръчки от различни страни, обработка на валутни курсове и управление на инвентара в множество складове.
• Банкиране: Записване на транзакции, проследяване на салда по сметки и одит на финансови дейности. Многонационална банка може да използва Event Sourcing за проследяване на транзакции в различни клонове и валути, осигурявайки пълна одитна следа.
• Игри: Проследяване на действията на играчите, промените в състоянието на играта и историята на събитията. Онлайн мултиплейър игри често използват Event Sourcing за поддържане на консистентно състояние на играта между множество играчи и сървъри.
• Управление на веригата на доставки: Проследяване на движенията на продукти, нивата на инвентара и графиците за доставка. Глобална логистична компания може да използва Event Sourcing за проследяване на пратки в различни страни, обработка на митническо освобождаване и управление на графиците за доставка.

Избор на правилната система за съхранение: Матрица за вземане на решения

За да ви помогнем да решите коя система за съхранение на домейнови събития е подходяща за вашето приложение, обмислете следната матрица за вземане на решения:

Практически идеи

Ето някои практически идеи за внедряване на Event Sourcing:

• Започнете от малко: Започнете с малък, добре дефиниран домейн, за да придобиете опит с Event Sourcing, преди да го приложите към по-големи, по-сложни домейни.
• Съсредоточете се върху домейна: Внимателно моделирайте вашия домейн и идентифицирайте ключовите домейнови събития.
• Изберете правилната система за съхранение: Изберете event store, който отговаря на изискванията на вашето приложение за производителност, мащабируемост и консистентност на данните.
• Внедрете версиониране на събития: Планирайте версионирането на събития от самото начало, за да осигурите обратна съвместимост.
• Наблюдавайте производителността: Наблюдавайте производителността на вашия event store и обработчиците на събития, за да идентифицирате потенциални пречки.
• Автоматизирайте внедряването: Автоматизирайте внедряването и управлението на вашата Event Sourcing инфраструктура.
• Обмислете компромисите: Event Sourcing включва компромиси. Разберете, че възникват сложности за ползите, получени от модела.

Заключение

Event Sourcing е мощен архитектурен модел, който предлага многобройни предимства, включително пълна одитна следа, временни заявки и подобрена производителност за определени операции. Въпреки това, той също така представя предизвикателства, които трябва да бъдат внимателно обмислени, като например сложност, евентуална консистентност и версиониране на събития. Чрез внимателен избор на система за съхранение на домейнови събития и прилагане на най-добри практики, можете успешно да използвате Event Sourcing за изграждане на мащабируеми, устойчиви и подлежащи на одит приложения.

Това ръководство предостави преглед на Event Sourcing и няколко популярни системи за съхранение на домейнови събития. Изберете най-добрата система, която да се съгласува със специфичните нужди на вашите проектни изисквания.

Не забравяйте, че това съдържание е предназначено за глобална аудитория, така че адаптирайте и приложете концепциите към вашите уникални обстоятелства и културен контекст. Event Sourcing принципите са универсални, но внедряването може да варира в зависимост от вашите специфични нужди и ресурси.